A computing system may include multiple processes or threads, which may utilize one or more shared resources. If a first process and a second process attempt to concurrently access a shared resource, data corruption or other errors may occur, or unexpected system behavior may occur. In order to prevent or mitigate such errors, a locking discipline may be defined and used by the computing system. For example, the first process may lock the resource, access the resource, and then unlock the resource. While the resource is locked, the second resource may not access the locked resource.
Locking disciplines may be defined and/or enforced, for example, by an Operating System (OS) of the computing system. Unfortunately, a locking discipline may be violated by one or more processes, for example, due to an “illegal” function call, thereby resulting in data corruption and other errors.
In some computing systems, dynamic monitoring of the accesses by a program to shared variables, as well as dynamic monitoring of lock acquisitions, may be used in order to partially detect violation of a locking discipline. Unfortunately, in some computing environments, it may be difficult to detect some or all of the accesses by a program to shared variables, or to detect some or all of the lock acquisitions. Additionally, this method may result in performance overhead, which may be difficult to dynamically control, for example, particularly if the monitoring is performed using instrumentation.
In other computing systems, a static analysis may be used in order to partially detect some possible violations of a locking discipline. Unfortunately, it may be difficult to determine statically, by observing a source code, which locks are held by a process or by a thread while accessing a shared resource. Accordingly, static analysis methods may be inaccurate, and may produce erroneous results, e.g., false detection of locking violations.
In still other computing systems, detection of locking discipline violations may be partially achieved by inserting “noise” into the computer program, for example, statements that affect the scheduling of the computer program, e.g., calls to sleep( ) and yield( ). The inserted noise may result in interleavings that are not typically exercised in the testing environment, thereby increasing the probability to exhibit concurrency bugs, including locking discipline violations. Unfortunately, this method may be difficult to implement in computing environments in which static or run-time monitoring of accesses to shared resources and locks is difficult. Additionally, if the computing system is required to fulfill timing constraints, or relies on particular hardware assumptions, then the inserted noise may be “illegal”, namely, may change the semantics of the program or may violate preconditions of the environment in which the program is required to run, thereby producing false detection of locking violations.